Skip to content

Set beeai-framework version to 0.1.83 - #768

Merged
jpodivin merged 1 commit into
packit:mainfrom
jpodivin:beeai_update
Aug 24, 2026
Merged

Set beeai-framework version to 0.1.83#768
jpodivin merged 1 commit into
packit:mainfrom
jpodivin:beeai_update

Conversation

@jpodivin

Copy link
Copy Markdown
Collaborator

No description provided.

@jpodivin
jpodivin requested review from lbarcziova and nforro August 20, 2026 07:26
@jpodivin
jpodivin force-pushed the beeai_update branch 3 times, most recently from 5fffc41 to a76532c Compare August 20, 2026 08:00
@lbarcziova

Copy link
Copy Markdown
Member

/packit test

@lbarcziova

Copy link
Copy Markdown
Member

@nforro do we have some criteria on what we usually check when bumping the version? Like running at least e2e tests, or trying few runs locally? I remember you were doing these for some bigger bumps, but we probably haven't formalised anything?

@jpodivin

Copy link
Copy Markdown
Collaborator Author

Change list for this release is at least relatively short. https://github.com/i-am-bee/beeai-framework/releases/tag/python_v0.1.83

@TomasTomecek TomasTomecek left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, since there are no significant upstream changes this looks safe

but I would wait for Monday so we have whole work week to figure out potential issues

@jpodivin

Copy link
Copy Markdown
Collaborator Author

LGTM, since there are no significant upstream changes this looks safe

but I would wait for Monday so we have whole work week to figure out potential issues

No problem. Given the changes merged, I do expect that one noticeable impact will be substantially higher verbosity of error messages. This may have a confounding effect on search in phoenix and issue categorization in Sentry. Other than that, I believe we should be fine.

@nforro

nforro commented Aug 24, 2026

Copy link
Copy Markdown
Member

@nforro do we have some criteria on what we usually check when bumping the version? Like running at least e2e tests, or trying few runs locally? I remember you were doing these for some bigger bumps, but we probably haven't formalised anything?

Not really, I was always just doing a sanity check of released changes and a few local runs with testing Jiras before and after the bump.

This also allows us to unpin mcp dependency and remove downstream patch

Signed-off-by: Jiri Podivin <jpodivin@redhat.com>
@jpodivin
jpodivin merged commit ec7c5ab into packit:main Aug 24, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants